The quest for an unhackable code This article discusses both the plausibility and necessity of an unhackable code. A father and son team from Calgary, Alberta, said they've created an unhackable. The father and son team were so sure of their code's security that they ran a contest in the summer of 2011 offering $100,000 to anyone who could crack it: no one was able to crack the code. The article then goes on to discuss that there isn’t exactly a need for an unhackable code as there are many encryption methods like “Advanced Encryption Standard (AES) that are so complex that they could not be broken by modern supercomputers in our lifetime.” The problem is people, not encryption.
Weak passwords present a bigger problem for IT security as the article points out, “the past six months have been replete with hacking stories, and not one has been because an encryption was broken." As we discussed in Chapter 5, strong passwords are necessary to ensuring network security. Encryption is important to IT security; however, companies need to implement defense in depth (which includes strong passwords) to effectively prevent a breach in their network.
Nokia Developer Database Compromised by SQL Injection In 2011, a Nokia Developer database became victim to a simple SQL injection and, as a result, part of an internal administration database was compromised. The portion of the internal database that was compromised contained user names and password hashes (along with their respective salts). According to the image posted in the article, the vulnerable page was search form which allowed for “unsantized/unfiltered” input. The attacker created a query to return stored information, in this case, usernames and passwords. Fortunately for Nokia, the company employs the use of hashing algorithms in their security policy and no plain-text passwords were stored.
Breifly discussed in a recent class lecture and discussed further in Chapter 9 of our textbook, there are several ways to protect against a SQL injection attack. Database developers can validate incoming data and queries by making sure they are in the expected data type (e.g., text, integer, or binary), size (e.g., 32 bis, 10 characters, or less than 5 KB), or format (e.g., DD/MM/YYYY) to protect the database. Also, incoming data can be sanitized to remove unacceptable characters that could be used to manipulate the SQL statement. Nokia could have prevented this security breach by simply adding code to validate and sanitize incoming data.
This article discusses both the plausibility and necessity of an unhackable code. A father and son team from Calgary, Alberta, said they've created an unhackable. The father and son team were so sure of their code's security that they ran a contest in the summer of 2011 offering $100,000 to anyone who could crack it: no one was able to crack the code. The article then goes on to discuss that there isn’t exactly a need for an unhackable code as there are many encryption methods like “Advanced Encryption Standard (AES) that are so complex that they could not be broken by modern supercomputers in our lifetime.” The problem is people, not encryption.
Weak passwords present a bigger problem for IT security as the article points out, “the past six months have been replete with hacking stories, and not one has been because an encryption was broken." As we discussed in Chapter 5, strong passwords are necessary to ensuring network security. Encryption is important to IT security; however, companies need to implement defense in depth (which includes strong passwords) to effectively prevent a breach in their network.
Nokia Developer Database Compromised by SQL Injection
In 2011, a Nokia Developer database became victim to a simple SQL injection and, as a result, part of an internal administration database was compromised. The portion of the internal database that was compromised contained user names and password hashes (along with their respective salts). According to the image posted in the article, the vulnerable page was search form which allowed for “unsantized/unfiltered” input. The attacker created a query to return stored information, in this case, usernames and passwords. Fortunately for Nokia, the company employs the use of hashing algorithms in their security policy and no plain-text passwords were stored.
Breifly discussed in a recent class lecture and discussed further in Chapter 9 of our textbook, there are several ways to protect against a SQL injection attack. Database developers can validate incoming data and queries by making sure they are in the expected data type (e.g., text, integer, or binary), size (e.g., 32 bis, 10 characters, or less than 5 KB), or format (e.g., DD/MM/YYYY) to protect the database. Also, incoming data can be sanitized to remove unacceptable characters that could be used to manipulate the SQL statement. Nokia could have prevented this security breach by simply adding code to validate and sanitize incoming data.
40/50